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Abstract 


The Internet Assigned Numbers Authority (IANA) maintains registries to track code points used 
by protocols such as those defined by the IETF and documented in RFCs developed on the IETF 
Stream. 


The Independent Submission Stream is another source of documents that can be published as 
RFCs. This stream is under the care of the Independent Submissions Editor (ISE). 


This document complements RFC 4846 by providing a description of how the ISE currently 
handles documents in the Independent Submission Stream that request actions from IANA. 
Nothing in this document changes existing IANA registries or their allocation policies, nor does it 
change any previously documented processes. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is published for informational 
purposes. 


This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor 
has chosen to publish this document at its discretion and makes no statement about its value for 
implementation or deployment. Documents approved for publication by the RFC Editor are not 
candidates for any level of Internet Standard; see Section 2 of RFC 7841. 


Information about the current status of this document, any errata, and how to provide feedback 
on it may be obtained at https://www.rfc-editor.org/info/rfc8726. 


Copyright Notice 


Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights 
reserved. 
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This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF 
Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this 
document. Please review these documents carefully, as they describe your rights and restrictions 
with respect to this document. 
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1. Introduction 


The Internet Assigned Numbers Authority (IANA) maintains registries to track code points used 
by protocols such as those defined by the IETF and documented in RFCs developed on the IETF 
Stream. A full list of registries and code points can be found at https://www.iana.org/protocols. 


Requests may be made to IANA for actions to create registries or to allocate code points from 
existing registries. Procedures for these operations are described in [RFC8126]. 


Many requests for IANA action are included in documents that are progressed for publication as 
RFCs. RFCs may be sourced from within the IETF (on the IETF Stream) but may also be sourced 
from other streams, including the Independent Submission Stream (the Independent Stream), as 
described in [RFC4846]. The Independent Stream is under the care of the Independent 
Submissions Editor (ISE). 
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This document complements [RFC4846] by providing a description of how the ISE currently 
handles documents in the Independent Stream that request actions from IANA. Nothing in this 
document changes existing IANA registries or their allocation policies, nor does it change any 
previously documented processes. 


If a case arises that is not precisely covered by this document, the ISE may discuss a solution with 
the interested parties, including IANA, the IESG, the stream managers for other streams, and the 
authors of an Independent Submission that requests IANA action. 


2. Allocations from Existing Registries 


Each IANA registry is governed by an allocation policy -- the rules that IANA applies to determine 
which code points can be allocated and under what circumstances. These policies are described 
in [RFC8126]. 


Documents proceeding from the Independent Stream will always follow the assignment policies 
defined for the registries from which they request allocations. Similarly, all code point 
assignments are subject to the oversight of any designated expert (DE) appointed for the registry. 


It should be noted that documents on the Independent Stream can never result in Standards 
Track RFCs and Independent Stream documents are never subject to IETF review. Thus, a 
registry whose policy is "IETF Review" or "Standards Action" [RFC8126] is not available to 
Independent Stream documents. 


3. Changing Policies of Existing Registries 


From time to time, a decision is made to change the allocation policy for a registry. Such changes 
are normally only made using the allocation policy of the registry itself and usually require 
documentation from the same stream that created the registry. 


Independent Stream RFCs will not seek to change the allocation policies of any registries except 
those created by documents from the Independent Stream. The list of such registries is itself very 
limited (see Section 4). 


4. Creating New IANA Registries 


Sometimes registries are needed to track a new set of code points for a new protocol or an 
extension to an existing protocol. 


In general, documents on the Independent Stream cannot request the creation of anew IANA 
registry. 
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The only exception to this rule is when a document to be published in the Independent 
Submission Stream requests the allocation of a code point from an existing registry with the 
allocation policy Specification Required, Expert Review, RFC Required, or First Come First 
Served. Then the document to be published may also need to create a registry that is tied to that 
specific code point and is used for interpreting a sub-code. 


Consider, for example, the "Uniform Resource Identifier (URI) Schemes" registry [URL- 
URIschemes]. From time to time, a URI scheme may need a registry of associated parameters; for 
example, consider the tel URI scheme that has a register of parameters called the "tel URI 
Parameters" [URL-telURI]. 


Such examples are rare and only exist to support the allocation from the base registry. In such 
cases, where there is an appointed DE for the existing base registry, the assignment of the 
individual code point from the existing base registry and the creation of the new registry can 
only happen if the DE approves both actions. 


There are several further constraints on the new registry: 


e The allocation policy for the new registry may only be First Come First Served, RFC Required, 
Experimental, or Private Use. In particular, no registry may be created that would require 
IETF action to achieve a future code point allocation. See Section 5 for an explanation of why 
the application of Specification Required and Expert Review are not acceptable policies for 
any registry created from a document in the Independent Stream. 


e If the allocation policy for the new registry is First Come First Served, the document must 
contain a brief statement and explanation of the expected arrival rate of new registrations 
over time. 


e The new registry must contain a clear statement of the escalation process for any issues that 
arise with the registry. A model for this statement is as follows: 


This registry was created by [RFCXXXX], which was published on the Independent 
Submission Stream. Any issues that arise with the management of this registry will be 
resolved by IANA in consultation with the Independent Submissions Editor. 


e The IESG will be invited to provide its opinions about the advisability of the creation of any 
new registries during its conflict review of the document [RFC5742], and the ISE will give full 
consideration to such opinions. 


Authors of Independent Submission Stream documents should consider the most appropriate 
venue to host such registries, taking into account where the expertise for managing and 
reviewing registry assignments may be found. In some cases, this may mean that registries are 
hosted by organizations other than IANA. 
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5. Assigning Designated Experts 


Some IANA allocation policies (specifically, Specification Required and Expert Review) utilize the 
review of a DE. The procedures applicable to the appointment and actions of a DE are described 
in Section 5 of [RFC8126]. 


When a DE is appointed, the position must be maintained and supported by whoever designated 
the DE in the first place. That is, someone must appoint replacement DEs if necessary, and 
someone must provide a backstop in case the appointed DEs are unresponsive. 


The ISE will not appoint a DE. That means that no subregistry created for Independent Stream 
documents will require the review of a DE. That means that no new subregistry can be created 
that uses the Specification Required or Expert Review policies. 


6. Transfer of Control 


Very rarely, it may be desirable to transfer "ownership" of an IANA registry from the 
Independent Stream to the IETF Stream. This might happen, for example, if a protocol was 
originally documented in the Independent Stream but has been adopted for work and 
standardization in the IETF. Such a transfer may require an IETF Stream RFC to act as the base 
reference for the registry and will require discussion and agreement with the ISE. 


Ownership of a registry will not be transferred from the IETF Stream to the Independent Stream. 


7. IANA Considerations 


This document is all about IANA actions but makes no request for IANA action. 


8. Security Considerations 


There are no direct security considerations arising from this document. It may be noted that 
some IANA registries relate to security protocols, and the stability and proper management of 
those registries contribute to the stability of the protocols themselves. That is a benefit for the 
security of the Internet and the users of the Internet. 
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